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Design of a Model Execution Framework: Repetitive 
Object-Oriented Simulation Environment (ROSE) 


Justin S. Gray and Jeffery L. Briggs 
National Aeronautics and Space Administration 
Glenn Research Center 
Cleveland, Ohio 44135 


Abstract 

The ROSE framework was designed to facilitate analyses of complex systems. It completely divorces 
the model execution process from the model itself. By doing so ROSE frees the modeler to develop a 
library of standard modeling processes such as design of experiments, optimizers, parameter studies, and 
sensitivity studies which can then be applied to any of their available models. 

The ROSE framework accomplishes this by means of a well defined API and object structure. Both the 
API and object structure are presented here with enough detail to implement ROSE in any object-oriented 
language or modeling tool. 


1 Introduction 

Today, state of the art systems analysis methods revolve around the ability to execute a given system model 
using statistical methods and optimizers. These methods need to be repeatable and widely applicable to a 
range of models, regardless of what modeling environment is used. There are many different programming 
languages and as many different modeling environments currently in active use today. C++, Java, Python, 
Fortran, Simulink, Model Center, iSight, and NPSS are just are just a few from the available language 
and modeling environment options. With so many options, there is a need for a unifying structure to 
define analysis processes and solution paths which can be easily applied in any language or modeling 
environment available. 

A second feature of almost any modern analysis methodology is the large case sets required to complete 
them. Optimizations and statistical methods all rely on the computational power available today to exe- 
cute many simulations of a given model in order to obtain the necessary information about it's behavior. 
Very often, the many individual simulations are completely independent of each other and can be executed 
concurrently, assuming the necessary parallel computing resources are available. In recent years, large clus- 
ters of inexpensive servers have provided an unprecedented level of parallel computing power. Similarly 
desktop workstations now come equipped with multi-core CPU's which can make use of parallelized pro- 
cesses. Any model execution framework needs to be able to seamlessly take advantage of these types of 
computation resources as they become available. 

The ROSE framework was designed primarily to serve the needs of a modern systems analysis method- 
ology. It addresses both the issue of creating general repeatable methodologies, as well as challenges in- 
volved with utilizing parallel computing resources. Presented here is a structural outline of the ROSE 
framework that is detailed enough to implement it in the language and/ or modeling environment of your 
choice, along with an example implementation written in Python. 


2 ROSE Design Philosophy 

The Repetitive Object-Oriented Simulation Environment (ROSE) was designed to be simple enough to be 
implemented in any object-Oriented programming language or modeling environment. Languages such 
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as Python [7] or modeling environments such as the Numerical Propulsion Systems Simulation (NPSS) [5] 
tool are both perfect examples of candidates for ROSE implementations. Analysis methods that are imple- 
mented using ROSE can be easily ported to any environment where ROSE itself has been implemented. 

To ensure that the analysis methods developed do not become specific to any given model, any pro- 
posed framework would need to completely divorce the model from the analysis method. [3] ROSE accom- 
plished this, and in doing so allows the analyst to develop analysis tools without undue consideration for 
the specifics of the model to be analyzed. Of course, certain model characteristics will inevitably affect the 
choice of available analysis methods. For instance, complex CFD simulations are slow and can be com- 
putationally unstable so it may be impossible to use one directly inside of a large optimization where it 
would need to be executed thousands of times. In that situation, a surrogate model would be appropriate. 
[2] However the important point is that whether the model is a surrogate or a CFD simulation of a wing 
in flutter, or a 1-D turbine engine model of a high-bypass turbofan, the same optimizers and probabilistic 
analysis tools developed in ROSE will still be applicable. 

To help generalize the interface between a Driver and a Model, attributes are described as key-value 
pairs within ROSE Models. All attributes can be described by a key representing the name of the attribute, 
and a value representing the data contained by the attribute. An attribute can be nearly any data type, 
and ROSE makes no specific assumption about which types will be used. This dissociation helps to further 
insulate a ROSE Driver design from any single language or modeling tool. By design, an analyst can use 
ROSE to generate many distinct Drivers, creating a library of possible analysis tools to choose from for any 
given analysis. 


3 ROSE API 

ROSE provides an analyst with the ability to create any type of model execution process he or she requires. 
To accomplish this a number of tools are made available to structure optimizers, parameter studies, design 
of experiments studies, uncertainty studies, etc. Each model execution process defined by an analyst is 
called a Driver. 

3.1 Driver Structure 

To build a Driver, ROSE provides five classes to use as building blocks. These 5 classes work together to 
capture all the parts of an execution process. The classes are listed below along with brief descriptions of 
their functions. 

• Iterator: Provides a Driver with model input values for each simulation 

• Outerator: Records model outputs from each simulation a Driver runs 

• Case: Data structure describing the inputs and outputs for a given simulation. 

• Operator: Responsible for communicating with whatever server or software is being used for model 
simulation 

• Conductor: Provides for communication between other ROSE classes and servers 

These classes serve as a skeleton for more complex objects needed to build Drivers. They can each be 
extended to create objects suited for specific tasks. For example, a simple Iterator can be created to read 
off case inputs from a comma separated value file, while a different Iterator can execute the complete set of 
available combinations from a set of inputs and their allowed values. Similarly, many different Operators 
can exist to facilitate communication with different computer clusters. Different Outerators can produce 
output in different forms, i.e. textual or database outputs. 

Regardless of the particular combination of Iterator, Outerator, Conductor, and Operator employed, 
all Drivers employ an iterative process to successfully complete a set of executions. Figure 1 portrays an 
effective iterative process that can be used for a wide range of Drivers. Here it is clear that execution begins 
in the Operator, whose StartQ method will grab a ready server and pass a pointer to it to the Conductor 


NASA/TM— 2008-215299 


2 



via a call back method. The Conductor is then responsible for determining the proper action for the given 
server, and utilizes the Iterator, Outerator, and Case objects to do it. Each object and its full role in any given 
Driver is explained in detail in the following sections. 

3.1.1 Case 

A Case is a data structure which holds the input and output information for a given simulation. It provides 
the following methods: 

• setlnput(key, value): Takes in an attribute key and a corresponding value, which it then adds to the 
list of key, value pairs for the case. Returns success or failure. 

• setOutput(key,[value]): Takes in a attribute key and optional value. Allows the user to add an at- 
tribute to be tracked as output, or allows user to set the value of an attribute associated with the given 
key. 

• getlnput(key): returns the input value associated with the prescribed key. 

• getlnputs(): returns a list of all key, value pairs of inputs in a case. 

• getOutput(key): returns the output value associated with the prescribed key. 

• getOutputs(): returns a list of all key, value pairs of outputs in a case. 

3.1.2 Iterator 

An Iterator is responsible for serving up cases to the rest of a Driver. There are no restrictions placed on 
how an Iterator determines which case or cases to serve or in what order they are served. It provides the 
following methods: 
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• initialize(): initializes the Iterator. Can be called at any time to re-initialize. Expected to return success 
or failure. 

• getNextCase([Number]): Takes an optional argument indicating how many cases should be returned 
in a list of cases, and defaults to a single case. Returns a list of pointers to Cases. It is expected to 
return an empty list of pointers when there are no more cases to execute. 

• cleanUp(): called at the end of a driver execution to allow the Iterator to perform any necessary 
operations such as releasing file resources or closing databases. 

3.1.3 Outerator 

An Outerator records the specified output from a given case. It provides the following methods: 

• initialize(): initializes the Outerator. Can be called at any time to re-initialize. Expected to return 
success or failure. 

• recordCase(caseName): Takes a pointer to a Case as an argument and records the output from that 
Case. Expected to return success or failure. 

• cleanUp(): called at the end of a drive execution to allow the Outerator to perform any necessary 
operations such as releasing file resources or closing databases. 

3.1.4 Operator 

An Operator is an object which acts as a translation layer between the other objects in a Driver and the 
server (or servers) which that Driver must communicate with. By abstracting the communication between 
the other Driver objects and Servers, the Operator class provides a simple way to switch between compu- 
tational resources without changing the rest of a Driver or the underlying analysis processes. In Figure 2 
the abstraction is evident. 

Operators are a unique class because they handle event driven sections of an analysis process. With 
an array of available servers the Operator will initiate a given simulation, using a call back function to a 
Conductor, when any server is ready to handle a simulation. An Operator should issue call backs based on 
servers becoming available until it is told to stop by an associated Conductor. 

Once the call back has been issued, a Conductor will make use of a set of function provided by the Oper- 
ator. These functions make up the Operator API, and they provide Conductors the means to communicate 
with models through the Operator. All of these functions must be non-blocking to ensure that execution 
does not need to wait for any particular model. All of these functions may return success or failure, but that 
determination should only be relative to the act of communicating with a particular server or model. In 
other words, if the Operator can not communicate with a particular server or a particular model on a par- 
ticular server, then these API calls should return Failure. If the call was issued to the proper server and/ or 
model successfully, then the API functions return Success. 

Operators provide the following methods: 

• initialize(): called to initialize the Operator. Can be called at any point to re-initialize. Should open 
connections to all servers and verify functional connection. Expected to return success or failure. 

• setConductor(conductorpointer): Specifies which Conductor to issue call backs to. Must be set before 
a start() is called. 

• start(): initiates the call backs to the paired Conductor. Expected to return success or failure. 

• cleanUp(): called at the end of a drive execution to allow the Operator to perform any necessary op- 
erations such as closing connections to servers or releasing system resources such as shared memory. 

• loadModel(serverpointer): Conductor issued call to load a model to the specified server. This function 
will instantiate a model on the server and initialize it. After a model is loaded, it is expected to be 
ready to execute cases. Expected to return success or failure. 
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Figure 2: Sequence diagram describing a simple communication example between the elements of a driver. 
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The Operator API consists of: 

• modelSet(serverpointer, key, value): Call to be used before a execution to set the value of the specified 
model attribute. Is not called during model execution. 

• modelGet(serverpointer, key, storage): Call to be used before or after model execution. It is not called 
during model execution. The argument "storage" provides the function with a location to put the 
retrieved value. 

• modelExec(serverpointer): Call to initiate the execution of a model. 

• modelSuccess(serverpointer, storage): Call to test for successful execution of a model. The argument 
"storage" is used to tell the function where to put the result of the function call. 

• modelCleanUp(serverpointer): Call used after a model execution has been completed to perform any 
necessary clean up operations on the model. This function can release system resources, close files, or 
do nothing. 

3.1.5 Conductor 

A Conductor provides a means of communication between all the other objects in a Driver. By using a 
Conductor to tie together the Iterator, Outerator, Operator, and Case objects it becomes simple to swap out 
components without needing to change the rest of the logic that ties a Driver together. 

A Conductor is designed to respond to call backs from an Operator. An Operator relies on a Conductor 
to indicate whether or not there are any more cases to run, and whether or not to continue to issue call 
backs. In Figure 2 this sequence is illustrated. The process begins at start, and runs until the Operator 
returns False for a serverRcady CB() call. 

A Conductor also provides the capability of a ROSE Driver to execute independent cases concurrently. 
It abstracts the asynchronous software requirements away from the rest of a Driver by maintaining relevant 
information about which server is doing what actions. Hence, when a Conductor receives call backs from 
an Operator, it is always given a pointer to the server that triggered the call back. Then it is the Conductor's 
responsibility to decide what to do with the server via the Operator API. 

Conductors provide the following methods: 

• initialize(): prepares the conductor to begin executing cases. Expected to return success or failure. 
After return, if successful, a conductor is considered ready to begin executing cases. 

• setOpera tor (opera torpointer): indicates which Operator the Conductor is currently paired to. Must 
be called before any call backs can be issued. 

• setIterator(itera torpointer): identifies which Iterator a Conductor should communicate with. Must be 
called before any call backs can be issued. 

• setOuterator(outera torpointer): identifies which Outerator a Conductor should communicate with. 
Must be called before any call backs can be issued. 

• serverready_CB(serverpointer): call back issued by the Operator indicating that the server, whose 
pointer is passed as the argument, is ready and waiting for the Conductor work with it. Returns a 
boolean: True if the Operator is to continue issuing call backs for that server. False if the Operator is 
to stop issuing call backs for that server. 


4 Implementation Example 

4.1 Overview 

To demonstrate the viability of the ROSE framework, an example implementation was developed using 
Python 2.5 [7], Python was chosen because it provided a well developed and powerful scripting language 
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along with a set of powerful extension modules for matrix manipulations [6] and 2-D or 3-D data plotting 
[4], A generic ROSE Driver was developed which allowed a Design of Experiments(DOE) to be executed 
on an arbitrary Numerical Propulsion Systems Simulation (NPSS)[5] model. This Driver was then used in 
conjuction with a DOE designed specifially for a complex model of a medium-bypass mixed flow turbojet, 
to facilitate a complex system level optimization of a supersonic business jet. 

The system level optimization contained a large number of design variables, resulting in a large number 
of simulations required by the optimizer to converge on a design. While NPSS is a powerful and flexible 
cycle analysis tool, it is also a fairly computationally intensive tool. A single case can take more than ten 
seconds to execute. Consequently using NPSS directly inside the aircraft optimization was not feasible. 

To conquer this issue, the ROSE DOE Driver executed the specified DOE (over 20,000 cases) on the given 
NPSS model, and the resulting data was used to build a fast executing meta model using response surface 
equations. The large case set was chosen to better illustrate the ROSE DOE Driver's capability. Though the 
execution of all 20,000 cases took about three days, the resulting metamodel could then be run many 10,000's 
of times in only minutes, thus drastically reducing the computational load of the engine calculations in the 
larger aircraft optimization. 
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Figure 3: Simple DOE created with Spreadsheet software. 


4.2 Iterator Design 

The first step in executing a DOE was to read in cases from that DOE. A comma separated value (CSV) 
file was chosen as the DOE format. The first row was used as a header row indicating the model attribute 
referred to in each DOE column. Successive DOE rows contained the attribute values to be used for each 
case. This format is simple to generate in an any spreadsheet program. Using this format, any extra model 
attributes that were needed for a simulation would simply be added by creating extra columns in the DOE. 
Similarly, any extra cases could be added by simply appending extra rows to the DOE. 

As an example, for the mixed flow turbo fan model. Figure 3 is a very simple DOE that would run 
12 simulations representing a simple study of the effects of fan pressure ratio, overall pressure ratio, and 
bypass ratio on engine performance. 

To read this DOE the Iterator parsed rows from the CSV file, and placed the data into a Case objects, 
whenever the getNextCase() method was called by a Driver. 

4.3 Outerator Design 

The data produced by a simulation gets recorded when the Case object containing the information for that 
simulation is passed to the recordCase() method of an Outerator. 

To make the data easily accessible once it has been stored the CSV format was reused. Once again, 
the header row represented the attribute name being tracked and each row contained the value from that 
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output attribute for that simulation. Additionally, it was useful to have the appropriate input information 
available in the same output, so the Outerator will store that data along with the case outputs in each row. 

4.4 Conductor Design 

Besides communications between all the other ROSE objects, the Conductor handles all the asynchronous 
simulation scheduling requirements that come along with concurrent executions. To accomplish this the 
Conductor utilizes a series of state tables to determine the proper action to take for any given Server- 
Ready _CB() from an Operator. Each callback provides a pointer to the server that triggered it. The Con- 




Figure 4: State machines for the server and case tracking 

ductor then checks which state that server is currently in. Using these state machines, a Conductor tracks 
the progress of an arbitrary number of Cases executing on an arbitrary number of servers. If the number 
of available servers just happens to be one, then the system will execute each Case successively. However, 
should more than one server become available the very same Conductor can orchestrate the execution of 
many Cases simultaneously, assuming that none of the calls in the Operator API are blocking. The Driver 
does not know, nor does it matter, a priori how many servers will be available for a given execution. The 
issue of concurrency then lies completely within the implementation of the Operator. 

There are four possible states: Empty, Ready, Complete, and Error. All servers enter the system in the 
Empty state, and move between states according to the rules of the state machine, shown in in Figure 4(a). 
The conductor will try to load a model into an empty server and initialize it, utilizing the ROSE API. If that 
action succeeds, the server moves to the Ready state. For a server in the Ready state, the Conductor sets 
some action executing on that server and then the server moves to the Complete state. When a callback is 
received for a server in the complete state, the Conductor will perform the necessary steps to re-initialize 
the model and return the server to the ready state. Also, at any point if there is some sort of communication 
error and the server is unavailable the Server can be moved into the Error State. From the Error state, it can 
be moved back to the empty state if communications can be re-established. 

Each time a ServerReady_CB() is made for a server the Conductor refers to a table that provides it with 
the particular Case running on that server. Then it utilizes that cases state machine, shown in Figure 4(b), 
to determine the proper action to be taken. Cases have five possible states: Un-Run, Running, Run Success, 
Run Failure, Re-Run. All cases start in the Un-Run state, when a server is free a case can be loaded into it, 
and moved to the running state. From there the case can either move to the Run Success or Run-Failure 
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states. Also, if some kind of communication error happens not related to the model itself, the case can be 
moved to the Re-Run state. A case could also move the Re-Run state from the Run-Failure if necessary. 

Having a separate state for the Re-Run cases was not strictly necessary, as the Un-Run state could have 
been used. But having a separate state for the Re-Run cases allowed for some special scheduling routines 
to be used to limit the impact of large numbers of Re-Run cases on execution time. 

4.5 Operator Design 

The Operator serves as the communication layer between the Conductor and the computational resources 
available to it. By design, the implementation of the conductor determines the amount of concurrent ex- 
ecution a Driver will handle. By swapping out one Operator for another, a single Driver could possibly 
utilize vastly different computational resources. For this implementation a simple single server Operator 
was written. A second Operator was also written which utalized the Python module Parallel Python to 
enable concurrent execution of multiple cases simultaneously if sufficicent resources are available. 

To achieve the greatest level of code portability, an extra layer of abstraction was used to allow a single 
Operator to communicate with a wider variety of models. The Conductor communicates with the Operator 
via the API. This operator in turn defines its own API, which allows it to communicate with any model 
class implementing that API. Constructing the Operator in this manner allowed it to communicate with 
both native Python models, as well as NPSS models wrapped in a special class which conformed to the 
model API. 

The advantage of this approach is obvious when considering the generation of new, more powerful, 
concurrent Operators. In this situation using the model API, none of the work put into interfacing external 
codes with Python is wasted. In this case, the object which wraps NPSS and implements the model API 
will just as easily communicate with any Operator that utilizes the same API. 

4.5.1 Model Interface 

The following documents the model interface mentioned above. This interface provides a lower level API 
between the Operator and the model itself. Models written using Python could be implemented with a 
given model object while models written in Matlab or some other modeling code could use their own 
model objects. 

A Model provides the following methods: 

• set(key,value): This method is used to set attributes of the model. The method is passed a key, pointing 
to a specific model attribute, and a value to set the attribute to. It is expected to return success or 
failure. 

• get(key): This method is used to retrieve the value of a model attribute identified by the given key. It 
is expected to return the specified value, or a failure. 

• initialize(): This method is called only once, immediately after model instantiation, for any given 
model instance. It is here that any initialization a model requires can occur. It returns a success or 
failure. 

• exec(): This method is called when a model is ready to execute. It will execute a model. It is expected 
to return nothing 

• setup(): This method is called each time just prior to the run() method, but after any set() calls are 
made to specify case inputs. It is designed to allow the modeler to create model reactions to inputs, 
as well as ensure that a model is prepared to execute properly before a run() is called. It is expected 
to return success or failure of the initiation 

• succeededQ: This method is called after run() returns. It is used to test the model for successful 
completion. It returns a success or failure. 

• cleanUp(): This method is used to perform any actions necessary to prepare a model for removal. 
This includes releasing of any system resources the model holds and no longer needs. 
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5 Results 


The ROSE framework discussed above was used to execute over 20,000 cases on a mixed flow turbojet 
engine model. The Driver reported the data in the CSV format defined the by the outerator used. Response 
surface equations (RSE's) were generated using the R statistical analysis toolkit [8]. R is capable of reading 
in the CSV format output by the Driver directly. The RSE's provided a very valuable tool for studying the 
design space of the engine model. Because they are so fast to execute, being simple semi-log expressions, 
the performance of any group of points in the design space were instantly accessible with a reasonable 
degree of accuracy. 

5.1 Engine Model Inputs and Outputs 

The engine model provided six parametric inputs, however only two of the inputs were design inputs. The 
remaining four inputs were operational settings which determined the flight condition and nozzle setting 
of the engine. 

Though the model contained only two degrees of freedom with respect to the design variables, the 
remaining four operational variables represented a massive operational envelope for any single design 
configuration. 

There were six RSE's generated: gross thrust, ram drag, fuel burn rate, nozzle exit static temperature, 
nozzle exit static pressure, and total engine weight. Resulting calculated values included net thrust, and 
thrust specific fuel consumption. 

5.1.1 Inputs 

• top-of-climb thrust: (design variabl e:TOCThrust) specified in lbs force, the engine gets designed to 
produce the specified amount of thrust at the top of climb flight condition. 

• fan pressure ratio: (design va r i abl e: Fan PRdes) specified as a ratio of the entrance pressure to the 
exit pressure, the fan was designed to produce the specified pressure ratio at the top of climb flight 
condition. 

• nozzle underexpansion factor: (operational variable:/Vnoz) specified as a fraction less than or equal to 
one, this setting determined the amount of under expansion the variable nozzle area would achieve. 

• altitude: (operational variable:*:///) specified in feet, this is the flight altitude the engine is operating at 

• mach: (operation variable:M N) specified as Mach number, this is the flight Mach number the engine 
is operating at 

• power code: (operational variable:/^') specified as a number between 10 and 50, this represents the 
power setting of the engine with 50 being the maximum thrust level of the engine at the current flight 
condition. 

5.1.2 Outputs 

gross thrust: 

log [Fgross) — 

8.542— alt*4.560xl0~ 5 +MN*1.395+PC*.01845+TOCThrust*1.618xl0~ 4 — FanPRdes*.3889+Knoz*. 5299 

(1) 

ram drag: 

log(D ram ) = 6.901 - alt * 4.41e - 5 + VMN* 4.163 + TOCThrust * 1.618 x 10” 4 - FanPRdes * .6189 (2) 
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fuel bum rate: 


\og{W fuel ) = 2.932+log(Fg)*.5304:—alt*2A62xl0~ 5 +MN*.5397+PC*.01595+TOCThi'ust*7.597 x 10 -5 

(3) 

net thrust: 

Pnet — Pgross Dram (4) 

nozzle exit static temperature: 

log (nozzleExitT s ) = 5.294-alt*5.553xl0- 6 +MN*.008531+PC*M4705+FanPRdes*.m3+Knoz*.8210 

(5) 

nozzle exit static pressure: 

log (nozzleExitPg) = .8419 — alt * 4.427 x 10 -5 — FanPRdes * .008796 + Knoz * 1.945 (6) 

thust specific fuel consumption: 

TSFC = Wf uel /F net (7) 

weight: 

log {weight) = 7.826 + 3.506 /FanPRdes 2 + TOCThrust * 1.454 x 10" 4 (8) 

nozzle weight: 

W nozzle = weight FanPRdes / 2 (9) 

5.1.3 RSE Analysis 

The RSE's provide a rapid and simple method of examining the effect of design changes on engine per- 
formance. Figure 5(a) shows the change in thrust lapse and fuel consumption for a series of different fan 
pressure ratios. As Mach number increases, the thrust of each of the engines drops. This data is examined 
with an assumed flight profile presented in figure 6. 

As the engines approach the top of climb flight condition, their thrusts all converge at around 6000 lbs. 
This behavior of the RSE's confirms that they exhibit the proper thrust trends, as the engine data used to 
generate the RSE's was all sized at the top of climb condition. However, the actual accuracy of the RSE's 
can be better examined in figure 5(b) where only the super sonic part of the flight profile is shown. Here it 
is clear that the engines do not all produce exactly 6000 lbs of thrust. Although the trends in the data are 
correct, the accuracy of any single data point may as much as 20%, such as the data for fan pressure ratio of 
1.5. 

The utility of RSE's in engineering design and optimization problems is well established [9]. What they 
can provide in terms of computational speed can often be at the expense of accuracy. The accuracy of the 
RSE's needed to calculate net thrust are further considered in figures 5(a) through 9. Figure 8(a) shows how 
well the gross thrust was prediced by the F gross RSE. The RSE performs very well at the higher altitudes, 
but is much less accurate at lower altitudes. Figure 8(b) shows the accuracy of the D ram RSE. This RSE 
is much more accurate throughout the whole altitude and mach number regime considered. These two 
RSE's together combine to predict the net thrust of any given engine at any given flight condition. Hence, 
there errors would be additive for net thrust. The residual plot in figure 9(b) shows that the errors for gross 
thrust predictions are well distributed across all thrust levels. Similarly figure 9(a) indicates that the RSE 
has better accuracy at the lower gross thrust levels than it does at higher ones. 
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Thrust & TSFC vs Mach 



(a) Full Mach Range 


Thrust vs Mach (supersonic only) 


— PR 1 .5 -K- PR 2.0 — A— PR2.5 -X- PR 3 0 PR 3.5 -a-PFiTo] 



Mach 

(b) Supersonic Mach Range 

Figure 5: Thrust vs flight Mach number is shown on the right axis. TSFC vs flight Mach number is shown 
on the left axis. 
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TSFC (Ib/lb/hr) 


Altitude vs Mach Flight Profile 



Figure 6: Assumed Mach vs Altitude flight profile used to generate performance data over the flight enve- 
lope. 


Engine Size & Weight per TOC Fn=6000 lbs 

— B— Wteng -9— Wteng+nozz 



Figure 7: Engine weight with and without a noise supressing nozzle 
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Figure 8: Comparisons for gross thrust and ram drag between the RSE predictions and NPSS model data 


NPSS data vs. parametric model for gross thrust 


NPSS data vs model residuals for gross thrust 




data 


log(data) 


(a) 45 degree 


(b) Residual 


Figure 9: A 45 degree plot and a residual error plot for the gross thrust response surface 
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6 Conclusion 


Using Python, a ROSE implementation was generated which followed a strict adherence to the ROSE API 
defined here. The result was a ROSE Driver that could execute an arbitrary DOE on an arbitrary model. 
Using the parallel python, package concurrent execution of individual cases was possible. This Driver 
was able to efficiently execute over 20,000 simulations of the computationally expensive NPSS model and 
provide the results in a manner which allowed efficient generation of the RSE's. 

The creation of two distinct Operators displayed the power of adhearing to the ROSE API. Each operator 
interfaced with the other Driver objects only through the API, and hence to the rest of the Driver did not 
change. However, one Operator was utilizing only a single server and offered no concurrent capability. 
The other Operator enabled conccurent execution, and hence offered a more powerful computation tool for 
large case sets. Similarly any Driver object could be replaced in the system to change the behavior of the 
driver. New Iterators and Outerators can be made and better Conductors can be created. 

Further use of the powerful Python modules available in the open source community could quickly 
result in Optimizers and statistical analysis Drivers which could provide capabilities similar to the Design 
Analysis Kit for Optimization and Terascale Applications (DAKOTA)[l], but with greater flexibility and 
extensibility. 
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